The present invention relates to security modules (SMs) used for performing encrypted related operations (for example, encryption of target data, decryption of target data, key management).
A hardware security module (HSM) is a physical computing device that safeguards and manages digital keys for strong authentication and provides crypto processing. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server. HSMs may possess controls that provide tamper evidence such as logging and alerting and tamper resistance such as deleting keys upon tamper detection. Each module contains one or more secure crypto processor chips to prevent tampering and bus probing.
Many HSM systems have means to securely backup the keys they handle either in a wrapped form via the computer's operating system or externally using a smartcard or some other security token. Because HSMs are often part of a mission-critical infrastructure such as a public key infrastructure or online banking application, HSMs can typically be clustered for high availability. Some HSMs feature dual power supplies and field replaceable components such as cooling fans, to conform to the high-availability requirements of data center environments and to enable business continuity.
Few of the HSMs have the ability to execute specially developed modules within the HSM's secure enclosure. Such an ability is useful, for example, in cases where special algorithms or business logic have to be executed in a secured and controlled environment. The modules can be developed in native C language, in .NET, Java, or other programming languages. While providing the benefit of securing application-specific code, these execution engines obey an HSM's Federal Information Processing Standard (FIPS) or Common Criteria validation.
A hardware security module can be employed in any application that uses digital keys. Typically, the keys must be of high-value, meaning there would be a significant, negative impact to the owner of the key if it were compromised. The functions of an HSM are: (i) onboard secure cryptographic key generation; (ii) onboard secure cryptographic key storage and management; (iii) use of cryptographic material; and (iv) use of sensitive data material; and (v) offloading application servers for complete asymmetric and symmetric cryptography. HSM are also deployed to manage Transparent Data Encryption keys for databases. HSMs provide both logical and physical protection of these materials, including cryptographic keys, from non-authorized use and potential adversaries. The cryptographic material handled by most HSMs are asymmetric key pairs (and certificates) used in public-key cryptography. Some HSMs can also handle symmetric keys and other arbitrary data.
Physical HSMs are very expensive to produce. Further, HSMs are dedicated to virtual machines (or at least one of a fixed amount of domains). Thus, if there are a lot of virtual machines in a mainframe computer system there may be not enough physical HSMs to cover all virtual machines, but privacy/security requirements still apply. In currently conventional HSMs, encrypted memory mechanisms may be used for crypto processing. Besides using HSMs, certain commercially-available cryptographic accelerators or a plastic card with a built-in microprocessor, used typically for electronic processes such as financial transactions and personal identification may be used. Mechanisms known as Central Processor Assist for Cryptographic Function (CPACF) or network HSMs, like certain commercially available information security solutions may be used for these purposes.
Further, a so-called Virtual HSM (VHSM) being a software suite for storing and manipulating secret data outside a virtualized application environment may be used. While a HSM is a physical device connected to the computer, this software provides HSM functionality through an application programming interface (API) in a virtual environment based on the Linux-based OpenVZ container technology.
The architecture of the virtual HSM consists of the following key components: (i) a VHSM virtual environment (VHSM VE) is the isolated environment that contains the VHSM server and secure storage. The server performs operations on secret data and storage keeps encrypted user data. Further a transport layer, where transport exchanges data between client and server virtual environments, is based on: (i) the Linux-based Netlink socket technology; and (ii) a client virtual environment, with a client API and accompanying utilities for accessing the VHSM server from a client environment.
Further in the art, there is a certain commercially-available set of CPU (central processing unit) code instructions that allows user-level code to allocate private regions of memory, called enclaves. Unlike normal process memory, “enclaves” are protected from processes running at higher privilege levels.
Support for the CPU instructions mentioned in the foregoing paragraph in the CPU is indicated in a CPUID command “Structured Extended Feature Leaf”, EBX bit 02, but its availability to applications requires BIOS (Basic Input/Output System) support and opt-in enabling which is not reflected in CPUID bits. The CPU instructions mentioned in the foregoing paragraph are based on a special trusted memory, in other words, processor reserved memory. Further code is sent to the machine as plain text.